프론트엔드 보안 헤더: 콘텐츠 보안 정책(CSP) 마스터하기

웹 애플리케이션이 점점 더 복잡해지고 상호 연결되는 오늘날의 디지털 환경에서는 보안 위협으로부터 보호하는 것이 무엇보다 중요합니다. 백엔드 보안이 종종 상당한 주목을 받지만, 프론트엔드 보안 역시 마찬가지로 중요합니다. 프론트엔드 보안 헤더는 첫 번째 방어선 역할을 하며, 브라우저에 어떻게 동작해야 하는지 지시하고 다양한 공격으로부터 사용자를 보호하는 메커니즘을 제공합니다. 이러한 헤더 중에서 콘텐츠 보안 정책(CSP)은 광범위한 위험을 완화하는 강력한 도구로 돋보입니다.

프론트엔드 보안 헤더란 무엇인가?

프론트엔드 보안 헤더는 웹 서버가 브라우저로 보내는 HTTP 응답 헤더입니다. 이 헤더에는 브라우저가 수신하는 콘텐츠를 처리하는 방법에 대한 지침이 포함되어 있습니다. 다음과 같은 일반적인 공격을 방지하는 데 도움이 됩니다:

• 크로스 사이트 스크립팅(XSS): 신뢰할 수 있는 웹사이트에 악성 스크립트를 주입하는 공격.
• 클릭재킹: 사용자가 인식하는 것과 다른 것을 클릭하도록 속이는 공격.
• 중간자 공격(Man-in-the-Middle Attacks): 사용자와 서버 간의 통신을 가로채는 공격.

가장 중요한 프론트엔드 보안 헤더는 다음과 같습니다:

• 콘텐츠 보안 정책(CSP): 브라우저가 리소스를 로드할 수 있는 소스를 정의합니다.
• Strict-Transport-Security (HSTS): 브라우저가 웹사이트와의 모든 통신에 HTTPS를 사용하도록 강제합니다.
• X-Frame-Options: 웹사이트가 iframe에 임베드되는 것을 방지하여 클릭재킹 공격을 완화합니다.
• X-XSS-Protection: 브라우저의 내장 XSS 필터를 활성화합니다. (참고: 종종 CSP로 대체되지만 여전히 방어 계층을 제공할 수 있습니다).
• Referrer-Policy: 요청과 함께 전송되는 리퍼러 정보의 양을 제어합니다.
• Feature-Policy (현재 Permissions-Policy): 개발자가 브라우저 기능 및 API를 선택적으로 활성화 및 비활성화할 수 있도록 합니다.

콘텐츠 보안 정책(CSP) 심층 분석

콘텐츠 보안 정책(CSP)은 사용자 에이전트가 특정 페이지에 대해 로드할 수 있는 리소스를 제어하는 HTTP 응답 헤더입니다. 이는 본질적으로 승인된 콘텐츠 소스를 화이트리스트에 추가하여 XSS 공격의 위험을 크게 줄입니다. 스크립트, 스타일시트, 이미지, 글꼴과 같은 리소스를 로드할 수 있는 출처를 명시적으로 정의함으로써 CSP는 공격자가 웹사이트에 악성 코드를 주입하는 것을 훨씬 더 어렵게 만듭니다.

CSP 작동 방식

CSP는 브라우저에 다양한 유형의 콘텐츠에 대한 승인된 소스 목록을 제공함으로써 작동합니다. 브라우저가 CSP를 위반하는 리소스를 만나면 해당 리소스를 차단하고 위반 사항을 보고합니다. 이 차단 메커니즘은 공격자가 HTML에 악성 코드를 주입하는 데 성공하더라도 해당 코드가 실행되는 것을 방지합니다.

CSP 지시문

CSP 지시문은 CSP 정책의 핵심 구성 요소입니다. 이는 다양한 유형의 리소스에 허용되는 소스를 지정합니다. 가장 일반적으로 사용되는 지시문은 다음과 같습니다:

• default-src: 모든 리소스 유형에 대한 기본 소스를 설정합니다. 이는 다른 더 구체적인 지시문이 정의되지 않은 경우 적용되는 대체 지시문입니다.
• script-src: JavaScript에 허용되는 소스를 지정합니다.
• style-src: CSS 스타일시트에 허용되는 소스를 지정합니다.
• img-src: 이미지에 허용되는 소스를 지정합니다.
• font-src: 글꼴에 허용되는 소스를 지정합니다.
• media-src: 오디오 및 비디오에 허용되는 소스를 지정합니다.
• object-src: Flash와 같은 플러그인에 허용되는 소스를 지정합니다. (가능하다면 플러그인을 허용하지 않는 것이 가장 좋습니다).
• frame-src: 프레임(iframe)에 허용되는 소스를 지정합니다.
• connect-src: 네트워크 요청(AJAX, WebSockets)에 허용되는 소스를 지정합니다.
• base-uri: <base> 요소에서 사용할 수 있는 URL을 제한합니다.
• form-action: 양식을 제출할 수 있는 URL을 제한합니다.
• frame-ancestors: <frame>, <iframe>, <object>, <embed>, 또는 <applet>을 사용하여 페이지를 임베드할 수 있는 유효한 부모를 지정합니다. 이 지시문은 클릭재킹에 대한 보호를 제공합니다.
• upgrade-insecure-requests: 사용자 에이전트에게 사이트의 모든 비보안 URL(HTTP를 통해 로드됨)을 보안 URL(HTTPS를 통해 로드됨)로 대체된 것처럼 처리하도록 지시합니다. 이 지시문은 HTTP에서 HTTPS로 마이그레이션하는 과정에 있는 웹사이트를 위한 것입니다.
• report-uri: 브라우저가 CSP 위반에 대한 보고서를 보내야 하는 URL을 지정합니다. `report-to`를 위해 사용이 중단되었습니다.
• report-to: `Report-To` 헤더에 정의된 그룹 이름을 지정합니다. 이를 통해 여러 보고 엔드포인트를 지정하는 등 보고에 대한 세밀한 제어가 가능합니다.

CSP 소스 값

소스 값은 리소스를 로드할 수 있는 출처를 정의합니다. 몇 가지 일반적인 소스 값은 다음과 같습니다:

• *: 모든 소스의 콘텐츠를 허용합니다 (프로덕션 환경에서는 사용하지 마십시오!).
• 'self': 보호된 문서와 동일한 출처(스키마, 호스트, 포트)의 콘텐츠를 허용합니다.
• 'none': 어떤 소스의 콘텐츠도 허용하지 않습니다.
• 'unsafe-inline': 인라인 JavaScript 및 CSS 사용을 허용합니다 (프로덕션 환경에서는 사용하지 마십시오!).
• 'unsafe-eval': 동적 코드 평가(예: eval(), Function()) 사용을 허용합니다 (프로덕션 환경에서는 사용하지 마십시오!).
• 'strict-dynamic': 마크업에 있는 스크립트에 논스(nonce)나 해시를 동반하여 명시적으로 부여된 신뢰가 해당 조상이 로드하는 모든 스크립트로 전파되어야 함을 지정합니다.
• 'unsafe-hashes': 특정 인라인 이벤트 핸들러를 허용합니다. 이는 복잡성과 제한된 이점으로 인해 일반적으로 권장되지 않습니다.
• data:: 데이터 URL(예: 임베디드 이미지)에서 리소스 로드를 허용합니다. 주의해서 사용하십시오.
• mediastream:: `mediastream:` URI를 미디어 소스로 사용할 수 있도록 허용합니다.
• blob:: `blob:` URI를 미디어 소스로 사용할 수 있도록 허용합니다.
• filesystem:: 파일 시스템에서 리소스를 로드할 수 있도록 허용합니다.
• https://example.com: 특정 도메인 및 포트의 콘텐츠를 허용합니다.
• *.example.com: example.com의 모든 하위 도메인 콘텐츠를 허용합니다.
• nonce-{random-value}: 일치하는 논스 속성이 있는 스크립트 또는 스타일을 허용합니다. 이를 위해서는 각 요청에 대해 서버 측에서 임의의 논스 값을 생성해야 합니다.
• sha256-{hash-value}: 일치하는 SHA256, SHA384 또는 SHA512 해시가 있는 스크립트 또는 스타일을 허용합니다.

CSP 모드: 강제(Enforce) vs. 보고 전용(Report-Only)

CSP는 두 가지 모드로 배포할 수 있습니다:

• 강제 모드: 이 모드에서 브라우저는 CSP를 위반하는 모든 리소스를 차단합니다. 이는 프로덕션 환경에 권장되는 모드입니다. CSP는 `Content-Security-Policy` 헤더를 사용하여 전송됩니다.
• 보고 전용 모드: 이 모드에서 브라우저는 CSP 위반을 보고하지만 리소스를 차단하지는 않습니다. 이는 CSP를 강제하기 전에 테스트하고 평가하는 데 유용합니다. CSP는 `Content-Security-Policy-Report-Only` 헤더를 사용하여 전송됩니다.

CSP 구현: 단계별 가이드

CSP 구현은 어려워 보일 수 있지만, 체계적인 접근 방식을 따르면 웹 애플리케이션을 효과적으로 보호할 수 있습니다.

1. 보고 전용 정책으로 시작하기

보고 전용 모드로 CSP를 배포하여 시작하십시오. 이를 통해 웹사이트의 기능을 중단하지 않고 위반 사항을 모니터링할 수 있습니다. 위반 보고서를 지정된 엔드포인트로 보내도록 report-uri 또는 report-to 지시문을 구성하십시오.

예제 헤더 (보고 전용): Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

2. 위반 보고서 분석하기

위반 보고서를 주의 깊게 분석하여 어떤 리소스가 왜 차단되고 있는지 식별하십시오. 이는 웹사이트의 리소스 의존성을 이해하고 잠재적인 보안 취약점을 식별하는 데 도움이 될 것입니다.

위반 보고서는 일반적으로 JSON 페이로드로 구성된 report-uri 또는 report-to 엔드포인트로 전송됩니다. 이 보고서에는 차단된 URI, 위반된 지시문, 문서 URI와 같은 위반에 대한 정보가 포함됩니다.

3. CSP 정책 구체화하기

위반 보고서를 기반으로 CSP 정책을 구체화하여 합법적인 리소스를 허용하면서도 강력한 보안 태세를 유지하십시오. 차단되는 리소스에 대해 특정 소스 값을 추가하십시오. 'unsafe-inline' 사용을 피하기 위해 인라인 스크립트 및 스타일에 논스나 해시를 사용하는 것을 고려하십시오.

4. 강제 모드로 전환하기

CSP 정책이 합법적인 리소스를 차단하지 않는다고 확신하면 강제 모드로 전환하십시오. 이렇게 하면 남아있는 모든 위반 사항이 차단되고 XSS 공격에 대한 강력한 보안 계층이 제공됩니다.

예제 헤더 (강제): Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

5. CSP 정책 모니터링 및 유지 관리하기

CSP는 한 번 설정하고 잊어버리는 해결책이 아닙니다. 웹사이트가 발전하고 새로운 보안 위협이 나타남에 따라 CSP 정책을 지속적으로 모니터링하고 업데이트하는 것이 중요합니다. 정기적으로 위반 보고서를 검토하고 필요에 따라 정책을 조정하십시오.

실용적인 CSP 예제

다양한 시나리오에 대한 몇 가지 실용적인 CSP 예제를 살펴보겠습니다:

예제 1: 간단한 웹사이트를 위한 기본 CSP

이 CSP는 동일한 출처의 콘텐츠를 허용하고 모든 소스의 이미지를 허용합니다.

Content-Security-Policy: default-src 'self'; img-src *

예제 2: 특정 스크립트 및 스타일 소스를 사용한 CSP

이 CSP는 동일한 출처와 특정 CDN의 스크립트를 허용하고, 동일한 출처의 스타일과 인라인 스타일을 허용합니다.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

예제 3: 인라인 스크립트에 논스를 사용한 CSP

이 CSP는 각 인라인 스크립트에 고유한 논스를 요구합니다.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mn0nc3'

HTML:

<script nonce="r4nd0mn0nc3">console.log('Hello, world!');</script>

중요: 논스 값은 각 요청에 대해 서버에서 동적으로 생성되어야 합니다. 이는 공격자가 논스를 재사용하는 것을 방지합니다.

예제 4: 클릭재킹 방지를 위해 프레임 조상을 제한하는 CSP

이 CSP는 페이지가 `https://example.com`을 제외한 모든 도메인의 iframe에 임베드되는 것을 방지합니다.

Content-Security-Policy: frame-ancestors 'self' https://example.com

예제 5: 'strict-dynamic'과 'self'로의 폴백을 사용하는 더 제한적인 CSP

이 CSP는 최신 브라우저를 위해 `strict-dynamic`을 활용하면서도 이를 지원하지 않는 구형 브라우저도 지원합니다. 또한 위반 모니터링을 위한 `report-uri`를 포함합니다.

Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

서버 측에서 `{random-nonce}`를 동적으로 생성된 논스 값으로 교체하는 것을 잊지 마십시오.

CSP와 단일 페이지 애플리케이션(SPA)

SPA에 CSP를 구현하는 것은 이러한 애플리케이션의 동적 특성으로 인해 어려울 수 있습니다. SPA는 종종 DOM을 생성하고 조작하기 위해 JavaScript에 크게 의존하며, 이는 신중하게 처리하지 않으면 CSP 위반으로 이어질 수 있습니다.

SPA에 CSP를 구현하기 위한 몇 가지 팁은 다음과 같습니다:

• 'unsafe-inline' 및 'unsafe-eval' 피하기: 이 지시문들은 SPA에서 가능한 한 피해야 합니다. 이는 애플리케이션의 보안을 크게 약화시킵니다.
• 논스 또는 해시 사용하기: 인라인 스크립트 및 스타일에 논스 또는 해시를 사용하십시오. 이것이 SPA에 권장되는 접근 방식입니다.
• Trusted Types 고려하기: Trusted Types는 DOM 기반 XSS 취약점을 방지하는 데 도움이 되는 브라우저 API입니다. 보안을 더욱 강화하기 위해 CSP와 함께 사용할 수 있습니다.
• CSP 호환 프레임워크 사용하기: 일부 프론트엔드 프레임워크(특정 구성의 React, Angular, Vue.js 등)는 CSP를 더 쉽게 구현하는 데 도움이 되는 기능을 제공합니다.

기타 중요한 프론트엔드 보안 헤더

CSP는 프론트엔드 보안의 초석이지만, 다른 헤더들도 포괄적인 방어 전략을 제공하는 데 중요한 역할을 합니다:

Strict-Transport-Security (HSTS)

Strict-Transport-Security (HSTS) 헤더는 브라우저에게 항상 HTTPS를 사용하여 웹사이트에 연결하도록 지시합니다. 이는 연결을 HTTP로 다운그레이드하려는 중간자 공격을 방지합니다.

예제 헤더: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: 브라우저가 사이트에 HTTPS를 통해서만 접속해야 한다는 것을 기억해야 할 기간(초 단위)을 지정합니다. 프로덕션 환경에서는 31536000초(1년)의 값이 권장됩니다.
• includeSubDomains: HSTS 정책이 도메인의 모든 하위 도메인에 적용됨을 나타냅니다.
• preload: 도메인이 브라우저에 미리 로드되는 HSTS 활성화 도메인 목록에 포함될 수 있도록 허용합니다. 이를 위해서는 Google이 유지 관리하는 HSTS 사전 로드 목록에 도메인을 제출해야 합니다.

X-Frame-Options

X-Frame-Options 헤더는 웹사이트가 iframe에 임베드될 수 있는지 여부를 제어하여 클릭재킹 공격을 방지합니다.

예제 헤더: X-Frame-Options: DENY

가능한 값:

• DENY: 출처에 관계없이 페이지가 iframe에 표시되는 것을 방지합니다.
• SAMEORIGIN: iframe의 출처가 페이지의 출처와 일치하는 경우에만 페이지를 iframe에 표시할 수 있습니다.
• ALLOW-FROM uri: iframe의 출처가 지정된 URI와 일치하는 경우에만 페이지를 iframe에 표시할 수 있습니다. 참고: 이 옵션은 더 이상 사용되지 않으며 모든 브라우저에서 지원되지 않을 수 있습니다.

참고: CSP의 frame-ancestors 지시문은 프레이밍을 제어하는 더 유연하고 강력한 방법을 제공하며 일반적으로 X-Frame-Options보다 선호됩니다.

X-XSS-Protection

X-XSS-Protection 헤더는 브라우저의 내장 XSS 필터를 활성화합니다. CSP가 XSS 공격을 방지하기 위한 더 강력한 솔루션이지만, 이 헤더는 특히 CSP를 완전히 지원하지 않을 수 있는 구형 브라우저에 대해 추가적인 방어 계층을 제공할 수 있습니다.

예제 헤더: X-XSS-Protection: 1; mode=block

• 1: XSS 필터를 활성화합니다.
• 0: XSS 필터를 비활성화합니다.
• mode=block: XSS 공격이 감지되면 페이지를 차단하도록 브라우저에 지시합니다.
• report=uri: XSS 공격이 감지되면 브라우저가 보고서를 보내야 하는 URL을 지정합니다.

Referrer-Policy

Referrer-Policy 헤더는 요청과 함께 전송되는 리퍼러 정보의 양을 제어합니다. 리퍼러 정보는 웹사이트 간에 사용자를 추적하는 데 사용될 수 있으므로 이를 제어하면 사용자 개인 정보를 향상시킬 수 있습니다.

예제 헤더: Referrer-Policy: strict-origin-when-cross-origin

일반적인 값:

• no-referrer: Referer 헤더를 절대 보내지 않습니다.
• no-referrer-when-downgrade: TLS(HTTPS)가 없는 출처에는 Referer 헤더를 보내지 않습니다.
• origin: Referer 헤더에 출처(스키마, 호스트, 포트)만 보냅니다.
• origin-when-cross-origin: 교차 출처 요청에는 출처를 보내고, 동일 출처 요청에는 전체 URL을 보냅니다.
• same-origin: 동일 출처 요청에는 Referer 헤더를 보내지만, 교차 출처 요청에는 보내지 않습니다.
• strict-origin: 프로토콜 보안 수준이 동일하게 유지될 때(HTTPS에서 HTTPS로)만 출처를 보내고, 덜 안전한 대상(HTTPS에서 HTTP로)으로는 헤더를 보내지 않습니다.
• strict-origin-when-cross-origin: 동일 출처 요청을 수행할 때 출처를 보냅니다. 교차 출처 요청의 경우, 프로토콜 보안 수준이 동일하게 유지될 때(HTTPS에서 HTTPS로)만 출처를 보내고, 덜 안전한 대상(HTTPS에서 HTTP로)으로는 헤더를 보내지 않습니다.
• unsafe-url: 출처에 관계없이 Referer 헤더에 전체 URL을 보냅니다. 민감한 정보가 노출될 수 있으므로 극도의 주의를 기울여 사용하십시오.

Permissions-Policy (이전 Feature-Policy)

Permissions-Policy 헤더(이전에는 Feature-Policy로 알려짐)는 개발자가 브라우저 기능 및 API를 선택적으로 활성화 및 비활성화할 수 있도록 합니다. 이는 애플리케이션의 공격 표면을 줄이고 사용자 개인 정보를 향상시키는 데 도움이 될 수 있습니다.

예제 헤더: Permissions-Policy: geolocation=()

이 예제는 웹사이트의 위치 정보 API를 비활성화합니다.

Permissions-Policy로 제어할 수 있는 다른 기능은 다음과 같습니다:

• camera
• microphone
• geolocation
• accelerometer
• gyroscope
• magnetometer
• usb
• midi
• payment
• fullscreen

다양한 플랫폼에서 보안 헤더 설정하기

보안 헤더를 설정하는 방법은 사용 중인 웹 서버나 플랫폼에 따라 다릅니다. 몇 가지 일반적인 예는 다음과 같습니다:

Apache

Apache에서는 .htaccess 파일이나 서버 구성 파일(httpd.conf)에 보안 헤더를 추가하여 설정할 수 있습니다.

.htaccess 구성 예제:

<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 Header set X-Frame-Options "DENY"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx

Nginx에서는 Nginx 구성 파일(nginx.conf)의 서버 블록에 보안 헤더를 추가하여 설정할 수 있습니다.

Nginx 구성 예제:

server {
 listen 443 ssl;
 server_name example.com;

 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header X-Frame-Options "DENY";
 add_header X-XSS-Protection "1; mode=block";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 ...
}

Node.js (Express)

Node.js에서는 Helmet과 같은 미들웨어를 사용하여 보안 헤더를 설정할 수 있습니다.

Helmet 사용 예제:

const express = require('express');
const helmet = require('helmet');

const app = express();

app.use(helmet());

// 필요한 경우 CSP 사용자 정의
app.use(helmet.contentSecurityPolicy({
 directives: {
 defaultSrc: ["'self'"],
 scriptSrc: ["'self'", "https://cdn.example.com"],
 styleSrc: ["'self'", "'unsafe-inline'"],
 imgSrc: ["'self'", "data:"],
 reportUri: '/csp-report'
 },
}));

app.get('/', (req, res) => {
 res.send('Hello World!');
});

app.listen(3000, () => {
 console.log('Server listening on port 3000');
});

Cloudflare

Cloudflare에서는 페이지 규칙(Page Rules) 또는 변환 규칙(Transform Rules)을 사용하여 보안 헤더를 설정할 수 있습니다.

보안 헤더 테스트하기

보안 헤더를 구현한 후에는 올바르게 작동하는지 테스트하는 것이 중요합니다. 웹사이트의 보안 헤더를 분석하는 데 도움이 되는 여러 온라인 도구가 있습니다:

• SecurityHeaders.com: 보안 헤더를 분석하는 간단하고 효과적인 도구입니다.
• Mozilla Observatory: 보안 헤더를 포함하여 웹사이트 보안을 테스트하는 포괄적인 도구입니다.
• WebPageTest.org: 워터폴 차트에서 HTTP 헤더를 볼 수 있습니다.

결론

프론트엔드 보안 헤더, 특히 콘텐츠 보안 정책(CSP)은 다양한 공격으로부터 웹 애플리케이션을 보호하고 사용자 보안을 강화하는 데 필수적입니다. 이러한 헤더를 신중하게 구현하고 유지 관리함으로써 XSS, 클릭재킹 및 기타 보안 취약점의 위험을 크게 줄일 수 있습니다. 보고 전용 정책으로 시작하여 위반 보고서를 분석하고 정책을 구체화한 다음 강제 모드로 전환하는 것을 기억하십시오. 웹사이트가 발전하고 새로운 위협이 나타남에 따라 보안 헤더를 정기적으로 모니터링하고 업데이트하여 웹사이트를 안전하게 유지하십시오.

프론트엔드 보안에 대한 사전 예방적 접근 방식을 채택함으로써 사용자와 비즈니스를 보호하는 더 안전하고 신뢰할 수 있는 웹 애플리케이션을 구축할 수 있습니다.